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ABSTRACT 



A system and a method for accessing a data store as objects 
from an object application. The accessed data store could be 
either an object data store or a non-object (e.g. relational) 
data store. Tlie system includes an object schema including 
meta data corresponding to a data store schema and an 
adapter abstraction layer. The adapter abstraction layer com- 
prises a first adapter, and a second adapter. One embodiment 
of the system includes an object schema manager to create 
and maintain the object schema at run time. It comprises a 
dynamic, scalable, centrally managed, and secure method 
for accessing data stored in both object and non-object (e.g. 
relational) data stores, effecting a consistent interface to the 
data store regardless of its underlying structure, or a method 
of transport and level of security. 

8 Claims, 1 Drawing Sheet 
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SYSTEM AND METHOD FOR ACCESSING tion from object stores to nonnobject stores and back again 

DATA STORES AS OBJECTS difficult and inefficient. 

Further difficulties are created by mapping tools that 
attempt to map objects to no n -object data stores. The com- 

This invention relates to a system and method for access- 5 ^on technique in such mapping is to 'generate' an object 

ing a data store — which could be either an object or a v ^ cw which is then embedded in the object application code, 

non-object data store — as an object from an object applica- Unfortunately any minor modification to the underlying 

tion. The system includes an object schema including meta non-object data store can break application code, thus cre- 

data corresponding to a data store schema and an abstraction aUQ S a 'brittle client'. As used in this application, brittle 

layer. In one embodiment, the abstraction layer includes a 10 cuent refers to a situation where a client application breaks 

first adapter and a second adapter. One embodiment of the under minor changes to the data store's physical layout (i.e. 

invention includes an object schema manager to create and da * a slore schema), which require no 'logical' changes in the 

maintain the object schema as meta data, and an access object application logic, but which requires embedded 

adapter to access and manipulate the data store using the access code to change in order to successfully use the object 

meta-data at run time. 15 application. Another common approach of the prior art is to 

use another intermediate, or an 'object store 1 , also com- 
BACKGROUND OF THE INVENTION monly referred to as a gateway (see e.g. U.S. Pat. No. 
Systems for accessing data stores from object oriented 5,542.078), where mapping occurs. While this is a workable 
languages have been used for many years. A frequent solution for some, many companies do not need nor want the 
approach to accomplish access of data stores involves writ- 20 extra management and complexity of yet another data store 
ing and embedding custom access code within an object s y stc m. The facilities provided for data management, 
application needing the access. This approach is generally ^gnty, and record locking are often duplicated in both 
limited to having the custom code access only a single systems unnecessarily, providing overly redundant and corn- 
relational table within a relational database or similar con- P lex s y stems - Most gateways also suffer in various degrees 
struct within any other data store (hereinafter collectively 25 from lack of Potability, security, and scaling, as they have 
"data store"). Under the circumstances where a developer *° route tbeir re 1 uests trough their data store to get to other 
has control over the design and creation of a data store from stores. 

its inception, it is possible to design and store meaningful Regardless of the logical solutions previously applied, the 

information in a single table. Such design opportunities are current systems do not properly address all of the aspects of 

usually rare, however. 30 creation, maintenance, security, and management properly. 

Generally, the design goals of a properly normalized Because extensive time is required to master both an 
relational data store for example conflict with those of object ad ™ nced data s y stem < su f h as a relational data store) 
application models. In most situations, the respective struc- and an advance <* ob J e u ct onented programming language, the 
tures simply do not conveniently allow for mapping of the « C ° S Ls ™ ih P ro l ects evolving both systems are 
application object into a single relational table. This results 35 oflen . vic ^ ed » expensive investments for the entities 
in application objects which logically span multiple rela- aeedm g the development. Generally, object oriented ac- 
tional tables, and which require multiple translation modules eation developers are not very ultimate with advanced data 
in order to do useful work. Such an approach is both costly store ( 1X '> re atlonal ) ^ and Performance tuning. Hav- 
and unwieldy in terms of computing and development An in S a centrally managed and controlled relational access 
resources system is essential for organizations concerned with the 

y ,i - , , A , , . , ... efficiency and mechanisms for accessing data stores. There 

In those circumstances where the object can conveniently ■ * * *_r u j j L • 

. . . i * . , , « - is no prior art system providing a much needed mechanism 

map to a single relauonal table, the general des.gn philoso- (Q ^ Ietel ski £ neMSSary (0 witn 

phy prevailing rn the programming induary k to embed obj frQm ^ Qe create ^ £ £ ^ 

access code in the application code itself Because toe 45 st0 J re sch emas and access code. 

current techniques involve the creation of custom code for . ,. , , . , . . „ , 

each table being accessed, it is costly and time consuming to t Accordingly there is a need to dynamically build the code 

create and maintain such access applications. It means That f °7.? oe ^ 1 ? g , tt " data store * ^^'^t ° n the obj£ f 

either custom objects for access must be created for each lts a " ribu u tes - as opposed to embeddmg the access code 

object(sucha SS bow Q inU.S.Pat.No.5,212,787),orthatthe 50 ° bjf f ™ ete * f° A"", ^ 

access code be embedded in the object itself, which is a maintenance costs of keepmg both object and data access 

common technique used in the industry. In either case, cod f. U P t0 dat * and in ^ Wlth 11 0ne another r m a " of l ' he 

separate database specific code must be embedded in an W>«""»» «>ft as well as allowing application data 

application object. Such code specific embedding affects objec * to ^ A w ° tk wth . ^ data store 

data store portability and code maintenance as well as 5S ^gardless of any differences in their access methods and 

significantly impacts distribution/bug-fix issues. access code. There is also a need for such an approach m 

" , . , . _ , . light of the explosive growth in the volume of new apph- 

The recent growth in popularity and acceptance of object ca(ions ^^Hy bci dev6 i oped for envu - onments suc h as 

oriented programming languages has required a more ^ Intemet which applications need t0 be d namic and ea 

objectK)nented view of data stores. There are many different , 0 e ^ fa a n66t , fof a ric object 

ypes and kinds ofdaU stores. The need to consistently view 60 mec hanism to bridge various underlying data stores 

the data stores with objects ,s universal. Current systems are consistentl especially in a transparent/generic, centrally 

inflexible, inconsistent and inadequate to meet this need. manageable , and secaK way . The present invention fills 

The common modeling technique of the current systems those needs 
is to map the underlying non-object data types directly as 

objects, as opposed to a more logical view of the data which 65 SUMMARY OF THE INVENTION 

may span many physical data stores or data store objects. The present invention comprises a system and method for 

Viewing non-object entities directly as objects makes migra- accessing a data store having a data store content and a data 
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store schema as object(s) from an object application. The the present invention comprises an object schema 200 

system comprises an object schema and an adapter abstrac- including meta data 201 corresponding to a data store 

tion layer. One embodiment of the adapter abstraction layer schema 300, a first adapter 400, and a second adapter 500. 

comprises a first adapter and a second adapter. The object In the preferred embodiment of the subject invention the 

schema includes meta data corresponding to the data store s object application 101 is a java applet "cocodemo.java" 

schema in some meaningful object-oriented view of data listed in appendix A. 

store content maintained at the data store. 0 ne embodiment of the present invention uses a user 

One embodiment of the subject invention comprises the defined object view of an underlying non-object store, i.e. 

first adapter in communication with the object application the object schema 200. The object schema 200 is accessed 

and includes an application bridge receiving an object 10 by an object application 101 through an abstract layer 600 

comprising object attributes and an object name. The first which does the necessary conversions between object and 

adapter also extracts the object attributes and the object non-object views. This abstraction allows both kinds of data 

name from the object to effect packing of the object stores — object and non-object (e.g. relational) — to be 

attributes and the object name as data. Upon receiving new accessed identically from at least one object application 101. 

attributes from the data store, the first adapter also unpacks is M oreo ver, by applying simple object streaming, the sub- 

the data to effect instantiating the object attributes and the j ect invention is capable of accessing objects distributed 

object name into a new object. over a threc ticr environment using exactly the same appli- 

The second adapter is in communication with at least one cation program interface ("API ") 700 as the local two -tier 

of the first adapter(s) and in communication with at least one environment. This is accomplished by using access "adap- 

data store. The second adapter includes (or dynamically 20 tive" technology comprising the adapter abstraction layer 

loads) a meta data map comprising object name(s) and 600. 

provides the data store content from at least one data store xh e adapter abstraction layer 600 of the subject invention 

corresponding to and based on the object attributes and the performs any translation work necessary for converting 

meta data. ^ objects to both object data stores 312 and non-object data 

One embodiment of the system uses an object schema stores 302. The adapter abstraction layer 600 provides a 

manager to create and manage the object schema to be used consistent API 700 for both object and non-object data stores 

at run time. and enables application programmers to migrate between 

The present invention discloses an improved data access various object stores without application modification. The 

system and, in particular, a dynamic, scalable, centrally 30 adapter abstraction layer 600 also facilitates communication 

managed, and secure method for accessing data stored in a remotely available second adapter 500 without modi- 

both object and non-object (e.g. relational) data stores. The tying the object application 101 programming logic, 

present invention effects a simple and consistent interface to In one embodiment, the subject invention includes the use 

at least one data store(s) regardless of its underlying of meta data 201 (i.e. data used to describe other data) to 

structure, or method of transport and level of security 35 define how to access and convert non-object data store 

implemented to access the data store. content 304 to objects and back. This is accomplished by 

paring down the non-object data store schema 300 into its 

BRIEF DESCRIPTION OF THE DRAWING various components including tables, fields, and conditions 

For the purpose of illustrating the invention, there is 305 in one embod ^ent. The paring makes the creation, 

shown in the drawing a form which is presently preferred; it 40 management, and access to the meta data 201 to be a 

being understood, however, that this invention is not limited element and elegant task. By using the adapter abstrac- 

to the precise arrangements and instrumentalities shown. I 1 ™ la u yer 6 U °° whl ° h understan .ds and uses the meta data 

FIG. 1 illustrates an object application request as it is 201 > * e sul f ct inve ^°n ^provides an abstract view of m 

processed by the present invention, such processing in dat * store ( s > 302 } m > 322 > M 30 ob J ect store - 

conjunction with a schema manager, and the way in which ^ The effected abstraction produces an architecture whereby 

the present invention further processes the request. th f data store(s) 302 (312) as well as multi-tier 

adapters (e.g. 400, 500, 4XX, and 5XX) may be inter- 

DESCRIPTION OF THE PREFERRED changed without object application 101 code modification. 

EMBODIMENT One embodiment of the subject invention is implemented 

«n.-i ,u • , . .j JL . . . .,50 using the adapter technology and is therefore capable of 

While the invention is described herein in connection with bd d { d as either ft ^ QI ^ a ^ env £ onment 

a preferred embodiment, it is understood that it v> not tT3nsvaTently , The adapter abstraction layer 600, and more 

mtended to limit the invention to that embodiment. To the specificall ±t ^ ad ter 400, communicates with a 

contrary it is intended to cover all alternatives, server process, more specifically the second adapter 500, in 

modulations and equivMents as may be included within 55 communication with me underlying data store 302, which 

T eXd cT " mventlon 38 dcfined b y tbe transfers the requested data store content 304 to and from the 

appen e c aims. ^ rsl adapter 400 in communication with object application 

An illustrative embodiment of a system and a method for 101 client. The first adapter 400 instantiates the object 112 

accessing a data store as an object from an object application from more primitive datatypes comprising data 115, reflect- 

may be implemented using a product such as CocoBase 60 in g the data store content 304 obtained from the server 

Family of products, products of Thought, Inc., an assignee process, more specifically the second adapter 500. The 

of the present invention, and the Java DataBase Connectiv- method of breaking down objects 102 (112) into the corre- 

ity Layer (JDBC), using a 3-tier architecture over a distrib- sponding primitive types comprising data 105 (115) ensures 

uted network such as an Internet, Extranet, or Intranet. successful transfers of any kind of object irrespective of 

FIG. 1 illustrates one such embodiment involving a 65 object application 101 views of the objects)' data elements, 

request 100 by an object application 101 and the processing The subject invention uses the adapter technology to 

of such request. The system according to one embodiment of dynamically load data store access code 205 at runtime. This 
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architecture requires objects to serialize themselves in order Query Language "SQL") from the object application 101 
to be persistable or for the computer language and language logic. This facilitates simple and rapid application deve lop- 
runtime to be able to inspect and set an object's structure in ment and lowers maintenance cost by improving the flex- 
such away as to be able to automatically persist the object's ibility of the object application 101 and by reducing the 
contents. Persistable is a term of art which means an object's 5 brittleness of the object application 101 clients). As a result, 
contents can be saved to some more permanent location such users of the subject invention attain a cost savings by 
as a computer disk, and in this case refers to the storage and centralizing the task, reducing the possibility of typographi- 
retrieval of the object's contents from a data store. As a cal errors, installation problems, and skills availability short- 
result, the present invention can readily adapt to an N-tier ages. The object stores can be created and managed by 
adapter solution which accesses the data store through some 3Q someone with data store (i.e. relational) expertise (as most 
intermediate data server, thereby increasing deployment and modern organizations have) without requiring those indi- 
scalability options. viduals to also have object programming expertise. 

FIG. 1 shows one embodiment of the present invention One embodiment of the subject invention results in an 

which works in conjunction with an object schema manager architecture for centrally storing and managing object 

203. The object schema manager 203 allows data store 15 schema 200 to promote re-use, effect enhanced performance, 

administrators to create and maintain an object view of data and better use of (MIS) engineering and administrative 

store content 301 stored in the data store 302. The object personnel skills. By way of example, storing the access code 

schema manager 203 reads, writes, and updates the meta 205 within the physical confines of the non-object data store 

data 201. One embodiment of the present invention directed 302 in one embodiment, creates a centrally manageable and 

to accessing non-object (e.g. relational) data stores 302, 2Q maintainable system for accessing that non-object store 302. 

creates meta data 201 based on data store schema 300 The object schema manager 203 thus allows for better use of 

comprising tables, fields and clauses or conditions 305, the MIS personnel's skill sets by focusing on data access in 

making up the data store 302. One such embodiment com- terms familiar to people maintaining their respective system, 

prises a set of tools which create and maintain the meta data That is, one embodiment of the subject invention allows 

201 by storing the information in a repository (such as the 25 object application engineers to concentrate on applications 

data store 302 itself), which information is then loaded by code without concern for or need to learn SQL or any other 

the second adapter at runtime. This meta data 201 then native access code 205 of the data store 302. At the same 

serves as a map for operations available on the data store(s) time, data store administrators may concentrate on manag- 

302 (312), for the way these operations should be performed ing and maintaining the data store(s) 302 without knowledge 

and under what conditions. 30 of application programming and without concern that any 

FIG. 1 further illustrates how the object schema manager changes in the data store content 301 or data store schema 
203 facilitates the creation and maintenance of the object 300 will adversely affect the object applications) 101 in 
schema 200, thereby increasing productivity and reducing communication with the data store(s) 302 according to one 
the opportunities for typographical errors, which can create embodiment of the subject invention, 
preventable runtime errors. The object schema manager 203 35 A central management architecture provided by one 
permits dynamic modification of object schema 200 without embodiment of the present invention allows data store 
requiring modification or recompile of the object application specialists to see, manage and control all access to the data 
101 to ensure the object application clients are not brittle' store(s) 302 down to the individual access code 205 com- 
as is traditionally the case in data store access applications. mands. It also allows for the fine tuning and reconfiguration 
One embodiment of the subject invention uses the meta data 40 of those commands by the data store specialists, without 
201 to construct an object view of the data store schema 300, involvement of object application developers. The architec- 
e.g. an object schema 200, and uses the meta data 201 to ture allows the best skills to complete the respective task at 
generate one or more commands 303 for accessing the data hand without impacting or being impacted by the lack of 
store content 304. The deployment of meta data 201 in this available skills that an individual may not have in the other 
way in one embodiment has the effect of using the non- 45 area. 

object data store(s) 302 to be described and accessed as In one embodiment of the subject invention the object 

objects) 102, thought its contents may be more rudimentary schema manager 203 allows for the arbitrary creation and 

and abstract. management of object schema(s) 200 via a point and click 

One embodiment of the subject invention stores meta data interface, thereby significantly increasing the efficiency of 

201 in a data store 204 and dynamically loads and executes 50 creating the data store access code 205, and improving the 

meta data 201 at runtime. Asa result, in one embodiment of reliability of the overall system. This embodiment also 

the invention access code 205 corresponding to the allows completely arbitrary joining and combining of the 

command(s) 303 is centrally created and managed in a data store content 301 as a single object view of that data, 

central repository, i.e. data store 204. Such central repository and overcomes the constrained and often uselessly arbitrary 

architecture allows object schema(s) 200 to be re-used 55 or non-existent foreign key constraints of conventional 

across objects 102 (112) and object applications 101 (111, mapping systems and data stores. These hardcoded links 

121). Such approach also allows for any changes of one such as foreign key constraints may not be supported 

object schema 200 to be transparently reflected to any client properly by all underlying data stores, and not be imple- 

object application 101 accessing and using the object mented by the specific customer's data store (often legacy) 

schema 200, without the need for object application 101 60 implementation. New foreign key constraints are often not 

modification or recompilation. The subject invention con- possible on some data stores because they may not work 

templates a notification mechanism so that data store 302 properly with older applications if the constraints were to be 

modifications resulting from requests in one location be created and enforced. 

immediately communicated to all object applications 101 As a point of reference, a foreign key is generally 

accessing that object schema 200. 65 accepted as a predefined relationship or link which the data 

One embodiment of the subject invention facilitates the store manages in order to ensure that records are properly 

separation of data store access code 205 (such as Structured related in a database. A simple example would be to have a 
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foreign key betweea an order number in an order table, and 
an order number in a line item table which keeps the 
individual items belonging to that order. The foreign key in 
this example would be between the order numbers in both 
tables, which might not allow, for example, a line item 5 
record to be entered if there is no order in the order table 
corresponding to the order number. 

A join using this embodiment may occur on any arbitrary 
field of any table within the data store schema 300, even if 
a foreign key does not exist between the fields of the two 1Q 
tables to be joined. Such flexibility is immeasurably useful 
when combined with the ability of the object schema man- 
ager 203 to access more than one data store 302 at the same 
time. The resulting architecture of the subject embodiment 
allows data store content 301 from one data store 302 to be 15 
joined with data store content 311 from another data store 
312 through the object schema manager 203 without requir- 
ing any data store schema 300 changes to either system 
whose content is being joined. Such transparent and inde- 
pendent flexibility is of utmost value for the many diverse 2Q 
data stores currently operated by most large and small 
business and other entities. 

One embodiment of the subject invention provides a way 
to manage the data store access code 205, requiring only an 
understanding of the data store 302 and the data store 25 
schema 300, instead of requiring object programming 
knowledge within the modem working environment. 

Once the object schema 200 is created, the object appli- 
cation 101 running in the application environment 103 sends 
a request 100 for an object 102 (possibly including an object 30 
data with lookup attributes to be matched) located in at least 
one data store such as an object data store 312 or a relational 
data store 302 in one embodiment of the subject invention. 
At a very high level, the request 100 is dynamically trans- 
lated to a data store specific request which is then executed 35 
and results of which are parsed and new data object(s) 112 
created and initialized with the results of the executed 
request 100. 

In one embodiment of the present invention, the request 
100 and the accompanying object 102 is passed from the 40 
object application 101 to the adapter abstraction layer 600 
comprising the first adapter 400. The first adapter 400 then 
extracts the object attributes 103 and the object name 104 
from the object 102, and packs the object attributes 103 and 
the object name 104 as data 105 to be used in communica- 45 
tion and transport layers. The first adapter 400 then com- 
municates the data 105 and the request 100 to the second 
adapter 500. The communication medium 630 between the 
first adapter 400 and the second adapter 500 may comprise 
an Internet connection, whereby the second adapter 500 is 50 
operating inside a firewall. Logical division 650 comprises 
a logical separation between a client, e.g. the object appli- 
cation 101, and a server, e.g. the abstraction layer 600 and 
more specifically the second adapter 500. 

The second adapter 500 searches a meta data map 206 55 
comprising at least one object name 114 using the object 
name 104 to determine whether the object name 104 exists 
in the meta data map 206. If the meta data map 206 contains 
the object name 104, then the second adapter 500 uses the 
object attributes 103 and the found meta data map 201 to 60 
generate at least one command 303 for accessing the data 
store 302 according to the request 100, if the command has 
been enabled, ensuring further security by restricting access. 
By way of example, the subject invention contemplates the 
use of this technology to provide read only data stores over 65 
the Internet, irrespective of the user's standard privileges 
within the context of the data store. 
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The second adapter 500 then executes at least one such 
command 303 as a data store access client server process 
500 in communication with the data store 302, and obtains 
the data store content 301 and an execution status 306 based 
on executing at least one such command 303. 

The second adapter 500 then processes the data store 
content 304 and the execution status 306 using meta data 
201, and packs the obtained data store content 304 and the 
execution status 306 as data 115. The second adapter 500 
communicates the data 115 to the first adapter 400. 

The first adapter 400 unpacks the data 115 and instantiates 
the object attributes 113 and the object name 114 into 
potentially one or more new object(s) 112 and/or status 
according to the request 100 and the data 115. The first 
adapter then communicates the request 100 and at least one 
such new object 112 and/or status, if object results were 
found, from the first adapter 300 to the application program 
101. 

Several points should be noted regarding the implemen- 
tation of the subject invention in the preferred embodiment. 
As each object(s) 102 data is being read from the data 
store(s) 302 (312), an instance of the object's class type (or 
potentially some generic container object) is instantiated (in 
the preferred embodiment a Java Class is instantiated for 
each set row result returned) and initialized to the row of 
attributes returned in the result set. Because Java can instan- 
tiate new objects based on classname, objects can be man- 
aged by the preferred embodiment of the subject invention 
even though it may have been unaware of their existence or 
composition at compile time. For ease of implementation, 
each java class in order to be supported by the preferred 
embodiment must implement a standard interface. With 
compliance to this standard interface, the subject invention 
can call the methods necessary to initialize the data 
automatically, making new instances automatic and trans- 
parent to the client object application 101. 

Implementation of explicit reference handling is not 
required using the subject invention, and therefore is not 
implemented in the preferred embodiment. Unlike more' 
rigid systems which limit the type of operation and mecha- 
nisms which will and can be used to access data stores, the 
subject invention allows for flexibility. This is to reflect the 
market reality that most organizations operate large systems 
in place which should be capable of being accessed from a 
variety of sources in a variety of different ways. Any 
attempts to manage references in these mixed environments 
would not only prove a futile exercise, but would complicate 
and reduce reliability, without providing the desired func- 
tionality. As for reference handling within the object 
application, the Java language which was used to implement 
the preferred embodiment, has language supported reference 
counting within its memory management and garbage col- 
lection software. It is contemplated by the subject invention, 
however, that specific adapters and data objects may be 
implemented with this architecture for specific data stores 
supporting appropriate reference handling management. 

The preferred embodiment of the subject invention uses 
an in-memory list to maintain object references, which list 
is either partially or fully prefetched. The object application 
may retrieve one object, all of the objects at once, or in 
blocks of default, or user defined size. Once the objects are 
in the memory list, they can be iterated through using their 
offset in the list as their index. The subject invention 
contemplates incorporating smart vectors which will auto- 
matically fetch Objects as they are requested from the vector 
itself, instead of the object application manually having to 
go back to the data store to request new blocks. 
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The preferred embodiment provides non-granular simple inline, and often unnecessary descriptive data that is 
transaction support, although the subject invention contem- returned, and which is unnecessary in a system which is 
plates either building it's own transaction management already preprogrammed with and understanding of the corn- 
system, or using a pass through mechanism which allows for position of the return values. 

more sophisticated transaction management to be written by s Because the first adapter 300 packs object requests) 100 
the application programmer, if the underlying system sup- as a single API 700 call returning a single complex result 
ports it. Any limitations due to the preferred embodiment (building the resulting data objects 112 transparently in the 
being implemented in the Java Driver Database Layer and client from the returned complex data 115 packet), the 
JDBC or the Java DataBase Connectivity Layer are not subject invention reduces network latency (which is essen- 
contemplated by the subject invention. Thus, the subject 10 tial to reduce over the Internet and other io-bound and high 
invention contemplates using more advanced transaction latency networks) and increases the performance and seal- 
management, as available in the implementing language and ability of the involved clients and servers. The subject 
architecture. invention also reduces the quantity of extraneous informa- 

When the subject invention is used to access the non- tion which is always returned to chent object applications by 
object data store 302, e.g. relational databases, the object 15 V^ 0T art systems such as the JDBC type-3 distributed 
schema 200 providing meta data 201 descriptions of how to database access layer architecture upon which other corn- 
map to the underlying data store 302 is used to generate the mon Java Database Products are currently built. As a result, 
native access code 205 necessary to access the data store not °nly does the present invention obtain tremendous 
content 304. One embodiment of the subject invention uses performance gains by reducing the latency of multiple 
the object schema 200 to build an SQL statement at runtime, 2 o network roundtrips, it also reduces the quantity of data and 
which is then executed to get the desired results, based on therefore increase the number of clients it can support, since 
the request 100. Because multiple statements are likely to be each request/response requires less I/O. Compression and 
executed against a given class type once it has been accessed data duplication reduction techniques are contemplated by 
once, the present invention caches the meta data for the class tne subject invention to further increase, performance, 
(name) in memory, within the second adapter 500 and saves 2 s New adapters, e.g. 4XX, 5XX, may be added to the 
pre-compiled versions of the access code 205 which can adapter abstraction layer 600 dynamically, even at runtime, 
simply be re-executed without recompile. This approach as long as they comply with the API 700. This allows data 
provides improved performance characteristics for succes- store(s) 302 (312) to have custom adapters built for them 
sive accesses. In the three-tier design embodiment of the (such as object data stores or other relational and/or non- 
subject invention, the cache is physically located on the 30 relational data sources) which comply with the API 700 of 
server, and is therefore shared across all client accesses to the subject invention and are loadable in the same way as the 
that server, providing a performance optimization in an area adapter abstraction layer 600 taught by the subject inven- 
where performance is most critical. tion. 

The present invention comprises the adapter abstraction With the burgeoning of the Internet, secure access to data 

layer 600 comprising a set of runtime adapters (e.g. the first 35 is essential. The subject invention implements security by 

adapter 400, the second adapter 500, the n-th adapter 4XX, using a novel approach in comparison to the current soft- 

5XX), which can be transparently interchanged by the object ware trends and prior art systems. That is, instead of creating 

application 101. The adapters serve various functions such 'embedded' access code which goes into a chent or a server 

as direct 2-tier data access, or 3 -tier or even n-tier gateway/ at creation time, and which must be conveyed to the server, 

transport. Because all adapters implement the same API 700, 40 which therefore must be opened up to these general request, 

they are interchangeable in the object application 101, the subject invention teaches extracting, managing, and 

providing new and useful functionality, even beyond the executing the access code exclusively and dynamically on 

subject implementation, without requiring object application the server for the described 3-tier system. As a result, one 

101 modification. Object application 101 runtime flags can embodiment of the subject invention relating to relational 

instantiate entirely new adapters which might interface with 45 data store allows an architecture which never exposes the 

radically different data store(s) 302 without modification to data store's native SQL interfaces to the Internet. This 

object application 101. approach eliminates the risk created by open SQL interface 

When data store access code, e.g. SQL, is dynamic verses based clients. The only SQL which can be executed is 

pre-compiled, there is typically some performance penalties controlled down to the table, field, and operations defined 

to be paid for dynamic execution. In the preferred 50 using the object schema manager 203 and is made available 

embodiment, the subject invention addresses these perfor- fr° m on ty ins ide of the corporate network and firewall. This 

mance issues by pre-compiling SQL the first time a given means that organizations can feel secure in knowing that 

SQL operation is executed, and by preserving the compiled hackers cannot steal passwords and create rogue, 

statement within the second adapter 500 for future execu- destructive, malicious, and/or prying clients which could 

tions from the same or a different first adapter 400. The 55 potentially corrupt, steal, and/or destroy valuable corporate 

subject invention binds variables to the statement, and data > unlike other systems currently available which simply 

re-issues the generated access code with the new SQL. As a re ly °n passwords and encryption instead of also creating 

result, the penalty as to dynamic execution becomes a slight architectural obstructions. 

overhead the first time an object 102 of a given type is As noted earlier, the preferred embodiment of the subject 

requested from the abstraction layer 600, Past this first point 60 invention was implemented using the Java programming 

the performance characteristics should be the same as from language, because of its dynamic language support, focus on 

any other embedded SQL client, perhaps even better because security, and its overall suitability for the Internet. In the 

the amount of information to be processed and transferred to interest of fullest possible disclosure, the following appen- 

the server accessing the data store 302 is likely to be less dices comprise the partial listing of the preferred embodi- 

using the architecture of the subject invention than one 65 ment. 

which embeds SQL within a client object application and CocoDemo is a demo applet which uses the CocoBase 

ships it with every request, and then must process the results three-tier adapter API to connect. Appendix A contains 
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"CocoDemo.java" (Copyright © 1996, 1997 Thought, Inc., 
All rights reserved), the demo applet performing the object 
application functions and using the API, and "Customer- 
.java" comprising a data object which implements the 
CBDrop serialization interface, and can therefore be cracked 5 
open and constructed by the subject invention. 

CocoBeanslmpl and CocoPowder together comprise the 
implementation of the second adapter and actually handle 
the server side communication and process the meta data 
and object attributes, and which executes the SQL. Appen- 
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dix B contains "CocoDriverlnterf ace Java" (Copyright © 
1996, 1997 Thought, Inc., All rights reserved), which imple- 
ments the API that the first adapter and CocoBeanslmpl/ 
CocoPowder classes both implement. 

The present invention may be embodied in other specific 
forms without departing from the spirit or essential attributes 
thereof and, accordingly, reference should be made to the 
appended claims, rather than to the foregoing specification, 
as indicating the scope of the invention. 



02/19/2004, EAST Version: 1.4.1 



13 



5,857,197 



14 



PBR/l 14837 



APPENDIX A 



10 



20 



25 



40 



Copyright © 1996, 1997 Thought, Inc., All rights reserved 

This class is a basic extension of the Applet class. It would generally be 
used as the main class with a Java browser or the AppletViewer But an 
instance can be added to a subclass of Container. To use this applet with a 
browser or the AppletViewer, create an html file with the follow^ codT 



<HTML> 

< HEAD > 

< TITLE > A simple program < /TITLE > 

< /HEAD > 
15 <BODY> 

< APPLET CODE = "CocoDemo. class" WIDTH=332 
HEIGHT = 169> </APPLET> 

</BODY> 
</HTML> 



*/ 



You can add controls to CocoDemo with Cafe Studio 
(Menus can be added only to subclasses of Frame.) 



import java.awt.*; 
30 import java.util.*; 

import java.applet.*; 
import thought. CocoBase.*; 
import Customer; 

35 public class CocoDemo extends Applet { 
CocoDriverlnterface myBase; 
public void initQ { 



super. initO; 

//{{INITCONTROLS 

setLayout(nulI); 

resize(374,262); 

c=new LabeI( H Customer Demo Applet"); 
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add(c); 

c.reshape(56,8,224,22); 
]abell=new Label("Name:"); 
add(labell); 

labe 1 1 . reshape( 1 9, 68, 70, 1 5) ; 
Iabel2=new Label ("Address:"); 
add(labe!2); 

label2.reshape(21, 98,70, 15); 
label3=new Labcl("Phone:"); 
add(labeB); 

IabeB . reshape(2 1 , 1 3 5 , 70, 1 5) ; 
editl =new TextFieId(26); 
add(editl); 

editLreshape(105 t 60,2i7,editl.preferredSize() height)- 

edit2 = new TextField(26); 

add(cdit2); 

edit2.reshape(105 t 98.217,cdit2.preferredSize0.height)- 

cdit3=.new TextField(26); 

add(edit3); 

edit3.reshape(105,135,217 f edit3.preferredSize().hfiight); 

findButton=new Button ("Find"); 

add(findButton); 

findButton.reshape(14,202,56,30); 
iasertButton=new Button("Insert"); 
add(insertButton); 

insertButton.reshape(91, 202,49,30); 
deleteButton=new Button(" Delete"); 
add(deleteButton); 

deleteButton.reshape(224,202,56,30); 
quitButton=new ButtonCQuit"); 
add(quitButton); 

quitButton.reshape(294,203,49 ( 30); 
updateButton = ne w Button( " Update ") ; 
add(updateButton); 

updateButton . reshape( 1 6 1 , 204 , 49, 29) ; 



// Create an initial driver. 

myBase=CocoDriver.getCocoDriy e r( w thought.CocoBase.CocoPowder" 
^jdbc.SimpleText.SimpleTextDriver" , 
"jdbc:SimpleText\ "rnyuser", "myuser"); 

if(myBase.connect() ~ - -1) 

System.out.prinflnCFailed connect!"); 
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public boolean hand leEvent(E vent event) { 
if(event.id == Event. KEY_PRESS) { 

if(event. target == editl && event.key == V) 
{ 

5 edit2. requestFocus() ; 

return true; 

} 

if(cvent. target == edit2 && event.key «« '\t*) 

1 0 edi t3 . requestFocus() ; 

return true; 

} 

if(event. target = = edit3 <fc& event.key = = V) 

15 editl. requestFocus(); 

return true; 

} 

} 

if (event.id == Event. ACTION EVENT && event.target 
20 quitButton) { " & 

cleanup(); 
return true; 

} 

else 

25 r ^ if l C y enUd " ^ vent * ACTION EVENT && evenl.target 
findButton) { 6 

flndCustomerO; 
return true; 

} 

30 else 

if (event.id == Event. ACTION EVENT && event.target 
insertButton) { 6 

insertCustomcrO; 
return true; 

35 } 

else 

if (event.id Event. ACTION EVENT && event.target 

updateButton) { ~~ 6 

updateCuslomer(); 
40 return true; 

} 

else 

if (event.id « Event. ACTION EVENT && event.target 
deleteButton) { ~ 6 

45 deleteCustomer(); 
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return true; 

} 

return super. handleEvent(event) • 

} 

5 

public void insertCustomer() { 

customer = new Customer(); 

customer. setName(edit 1 . getText()) ; 

customer.setAddress(edia.getTextO); 
1 0 customer. setPhone(edit3. getText()) ; 

int insNum = myBase.insert(customer); 
^ edlg.displayMsgf Inserted "+insNum + " Object(s) into RDBMS"); 

public void findCustomer() { 
15 Customer key Customer = new CustomerO; 

keyCustomer. setName(edi tl .getText()) ; 

customer = ((Custoraer)(myBase.select(keyCustomer))); 

//customer = ((Customer)(myBase.cal](keyCustomer)));' 

if(customer ! = null) 
20 { 

ed it 1 . setText(customer . getName()) ; 
edit2,setText(customer.getAddress()); 
edit3 .setText(customer. getPhone()); 

25 else 

edlg. displayMsgCCustomer * " + keyCustomer. getName() + " ' not 

Found!"); 
} 

public void updateCustomer() { 
30 // New values for customer 

if(customer =* « null | | (customer ! = null && 

! customer. getName() .equals(editl . getText()))) { 
customer = new Customer(); 
customer. setName(editl . getTextO) ; 

35 } 

Customer updateCustomer = (Customer) (customer. clone()); 
updateCustomer.setAddress(edit2.getText()); 
updateCustomer. setPhone(edit3. getText()); 
int insNum = myBase.update(customer,updateCustomer); 
40 edlg.displayMsgf Updated n +insNum + M Object(s) in RDBMS"); 

public void deleteCustomer() { 
customer = new CustomerO; 
customer. setName(editl. getText()); 
*5 int delRows = myBase.delete(customer); 
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edlg.displayMsg("De]eted "+delRows+ M Objcct(s) from RDBMS" 

editl.setTextr"); 

edit2.setText(' ,M ); 

edita.setTextr"); 

5 } 

public void cleanupO { 
myBase.closeO; 
System.exit(0); 

} 

10 //{{DECLARE_CONTROLS 

Label c; 

Label label 1; 

Label label2; 

Label labeB; 
15 TextField editl; 

TextField edit2; 

TextField edit3; 

Button findButton; 

Button insertButton; 
20 Button deleteButton; 

Button quitButton; 

Button updateButton; 

")} 

Customer customer; 
25 ErrorDialog edlg = new ErrorDialogfNONE"); 

} 
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/* 

* %W% %E% 



* Copyright (c) 1995-1997 THOUGHT Inc. All Rights Reserved. 
*/ 

package thought. CocoBase; 



import java.util.*; 
import java.sql.*; 
15 import thought. CocoBase.*; 

/** 

* < H3 > PROPRIETARY PROPERY of THOUGHT Inc. </H3 > 
+ <pre> 

20 * Copyright (c) 1996 THOUGHT Inc. All Rights Reserved. 

* </pre> 

* CocoBase class (DataBase Catalog access class, designed for Catalog driven 

* access to relational databases, Meta Access Software System). <p> 



* A class to access relational databases in a more object oriented fashion. 



* ©author Ward Mullins 
30 */ 

public interface CocoDriverlnterface { 
/** 

* Post Constructor set methods for CocoBase. 

* Example usage: 

35 ^ ^ . * CocoDriver myBase = new 

CocoDnverC'thought.CocoBase.CocoPowder", 

* "jdbc.odbc.JdbcOdbcDriver", 
"jdbc:odbc:Sademo", "sql", "dba")- 

* <§>param myCIass the Connection Class 

40 * @param connectDrivcr the JDBC Connection driver to be used 

* ©param connectURL the URL to use in connecting to the database 
instance 



45 



* @param userlD the User Id to log into the database with. 

* ©param password the Password to log into the database with. 
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public void setDebug(boolean debug); 
public void setUseBinding(boolean useBinding); 
public void setUseSchemaPrefixes(boolean useSchemaPrefixes); 
public boolean getDebug(); 
5 public boolean getUseBinding(); 

public boolean getUseSchemaPrefixesO; 
public void setConnectDriver(String connectDriver); 
public void setConnectURL(String connectURL); 
public void setUserld (String userld); 
10 public void setPassWord(String passWord); 

/** 

* Get a handle to the Connection object. This will ONLY work in a 

* ©return The Connection object. 
*/ 

15 public Object getConnection(); 

/** 

* Do a commit on the database! 
+/ 

20 public void commit(); 

/** 

* Do a rollback on the database! 
*/ 

25 public void rollbackO; 

* Set AutoCommit value 

30 * ©Param autoCommitValue The flag of whether or not to autoCommit 

public void setAutoCommit(boolean autoCommit Value)- 
/** 

* Return a ResultSet describing the columns which would be returned from 

* the Catalog manager for catalogName 

35 * @param catalogName the catalogName to find metadata for 

*/ 

public Vector getColumns(String catalogName); 
/** 

40 * Return a ResultSet describing the columns which would be returned from 

* the Catalog manager for anObject 

* @param anObject the Object to find metadata for 
*/ 

public Vector getColumns(Object anObject); 
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/** 

* Connect to the database using the current connection information 
*/ 

public int connectO; 

5 

/** 

* Fetch a Collection of all objects matching the criteria in myObject, 

* and using the definition associated with catalogName 

* @param myObject the object to used as a 'template' 

10 * @param catalogName the definition name of object to be retrieved (if 

* null use object name). 
*/ 

public Vector selectAll(Object myObject); 
15 /** 

* Fetch a Collection of all objects matching the criteria in myObject, 

* and using the definition associated with catalogName 

* @parara myObject the object to used as a 'template* 

* @param catalogName the definition name of object to be retrieved (if 
20 * null use object name). 

+/ 

public Vector selectAll(Object myObject, String catalogName); 

25 * Fetch a single object matching the criteria in myObject, and using 

* the definition associated with catalogName. If more than one object 

* matches the fetch, only the first is returned! 

* @param myObject the object to used as a 'template' 

* @param catalogName the definition name of object to be retrieved (if 
30 * null use object name), this allows for multiple maps for the 

* same Java 'object'. 
*/ 

public Object select(Object myObject); 
/** 

35 * Fetch a single object matching the criteria in myObject, and using 

* the definition associated with catalogName. If more than one object 

* matches the fetch, only the first is returned! 

* ©param myObject the object to used as a 'template' 

* @param catalogName the definition name of object to be retrieved (if 
40 * null use object name), this allows for multiple maps for the 

* same Java 'object'. 
*/ 

public Object select(Object myObject, String catalogName); 
45 /** 
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* Fetch the Number of objects matching the criteria in myObject, and using 

* the definition associated with catalogName. Return up to the number 

* of objects matched in by numberFinds 

* @param myObject the object to used as a 'template' 

5 * @param catalogName the definition name of object to be retrieved (if 

* null use object name), this allows for multiple maps for the 

* same Java 'object'. 

* @param numberFound the maximum number of objects to return 
*/ 

10 public Vector select(Object myObject, String catalogName, int 

numberFound); 

/** 

* Fetch a Collection of all objects matching the criteria in myObject, 
15 * and using the definition associated with catalogName 

* @param myObject the object to used as a 'template' 

* @param catalogName the definition name of object to be retrieved (if 

* null use object name). 
*/ 

20 public Vector callAll(Object myObject); 

/** 

* Fetch a Collection of all objects matching the criteria in myObject, 

* and using the definition associated with catalogName 
25 * @param myObject the object to used as a 'template' 

* @param catalogName the definition name of object to be retrieved (if 

* null use object name). 
*/ 

public Vector callAll(Object myObject, String catalogName); 
/** 

* Fetch a single object matching the criteria in myObject, and using 

* the definition associated with catalogName. If more than one object 

* matches the fetch, only the first is returned! 

35 * @param myObject the object to used as a 'template' 

* @param catalogName the definition name of object to be retrieved (if 

* null use object name), this allows for multiple maps for the 

* same Java 'object*. 
*/ 



30 



40 



45 



public Object caIl(Object myObject); 
/** 

* Fetch the Number of objects matching the criteria in myObject, and using 
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* the definition associated with catalogName. Return up to the number 

* of objects matched in by numberFinds 

* Oparam my Object the object to used as a 'template' 

* @param catalogName the definition name of object to be retrieved (if 
5 * null use object name), this allows for multiple maps for the 

* same Java * object'. 

* @param procName the Name of the stored procedure to execute. 

* @paiam numberFound the maximum number of objects to return. 
*/ 

10 public Vector call(Object my Object ( String catalogName, int numberFound) ; 

/** 

* Insert Object into Database 

* @param anObject the Object to insert into the catalog 
15 */ 

public int insert(Object anObject); 

/** 

* Insert Object into Database Using Catalog 

20 * @param anObject the Object to insert into the catalog 

* @param catalogName catalog name of Object (if null, use object Name), 

* this allows for multiple maps for the same Java 'object'. 
*/ 

public int insert(Object anObject, String catalogName); 

25 

/** 

* Delete Object into Catalog 

* @param anObject the Object to insert into the catalog 
*/ 

30 public int delete(Object anObject); 

/+* 

* Delete Object into Catalog 

* @param anObject the Object to insert into the catalog 

35 * @param catalogName catalog name of Object (if null, use object Name), 

* this allows for multiple maps for the same Java 'object*. 
*/ 



40 



public int delete(Object anObject, String catalogName); 
45 /** 
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* Update Object in Catalog. 

* Both anObject and newObject should be of the same object type! 

* @param anObject the Original Object being updated 

* @param newObject the new value of anObject 
5 */ 

public int update(Object anObject, Object newObject); 
/** 

10 * Update Object in Catalog, 

* Both anObject and newObject should be of the same object type! 
+ @param anObject the Original Object being updated 

* @param newObject the new value of anObject 

* @param catalogName catalog name of Object (if null, use object Name) 
15 * this allows for multiple maps for the same Java 'object'. 



public int update(Object anObject, Object newObject, String catalogName); 

20 * Close the connection to the Catalog, and to the Database. 

*/ 

public int close(); 

} 

25 
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I claim: 

1. A system for accessing at least one data store having a 
data store content and a data store schema as at least one 
object from at least one object application comprising: 

at least one object schema including meta data corre- s 
sponding to the data store schema; 

an adapter abstraction layer having a first interface 
responsive to the object application including an appli- 
cation bridge receiving an object comprising object 
attributes and an object name from the object 1Q 
application, said first interface extracting the object 
attributes and the object name from the object to effect 
packing of the object attributes and the object name as 
data, said first interface unpacking the data to effect 
instantiating the object attributes and the object name 15 
into a new object, and a second interface in commu- 
nication with said first interface and in communication 
with at least one data store, said second interface 
having a meta data map comprising at least one object 
name and providing the data store content from at least 2Q 
one data store corresponding to the object attributes and 
the meta data. 

2. A system according to claim 1 wherein the first inter- 
face comprises a first adapter and the second interface 
comprises a second adapter. 

3. A system for accessing at least one data store having a 
data store content and a data store schema as at least one 
object from at least one object application comprising: 

at least one object schema including meta data corre- 
sponding to the data store schema; 

a first adapter responsive to the object application includ- 
ing an application bridge receiving an object compris- 
ing object attributes and an object name from the object 
application, said first adapter extracting the object 
attributes and the object name from the object to effect 35 
packing of the object attributes and the object name as 
data, said first adapter unpacking the data to effect 
instantiating the object attributes and the object name 
into a new object; and 

a second adapter in communication with said first adapter 4Q 
and in communication with at least one data store, said 
second adapter having a meta data map comprising at 
least one object name and providing the data store 
content from at least one data store corresponding to 
the object attributes and the meta data. 45 

4. A system according to either of claim 2 or 3 further 
comprising an access code used to access the data store 
wherein said access code is separate from the object appli- 
cation. 

5. A system according to either of claim 1, 2 or 3 wherein 
said object schema comprises a possible arbitrary joining of 50 
the data store content across at least one data store. 

6. A system according to either of claim 1, 2 or 3 further 
comprising an object schema manager in communication 
with at least one object schema and at least one data store 
schema, said object schema manager including constructs, 55 
facades, objects, and methods, to effect meta data based on 

at least one object schema and at least one data store schema. 

7. A method for accessing at least one data store having 
a data store content and a data store schema as at least one 
object from at least one object application comprising the 60 
steps of: 

creating at least one object schema including meta data 

corresponding to the data store schema; 
communicating a request including an object comprising 

object attributes and an object name from the object 65 

application to an adapter abstraction layer having a first 

interface and a second interface; 
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extracting the object attributes and the object name from 
the object; 

packing the object attributes and the object name as data; 
communicating the data and the request from the first 

interface to the second interface; 
searching a meta data map comprising at least one object 

name using the object name to determine whether the 

object name exists in the meta data map; 
if the meta data map contains the object name, using the 

object attributes and the meta data to generate at least 

one command for accessing the data store according to 

the request; 
executing at least one such command; 
obtaining data store content and/or an execution status 

based on executing at least one such command; 
processing the data store content using meta data; 
packing data store content, if found, as data; 
communicating the data and the execution status from the 

second interface to the first interface; 
unpacking the data; 

instantiating the object attributes and the object name into 
at least one new object and/or status according to the 
request and the data; and 
communicating the request and at least one such new 
object and/or status from the adapter abstraction layer 
to the application program. 
8. A method for accessing at least one data store having 
a data store content and a data store schema as at least one 
object from at least one object application comprising the 
steps of: 

creating at least one object schema including meta data 

corresponding to the data store schema; 
communicating a request including an object comprising 

object attributes and an object name from the object 

application to a first adapter; 
extracting the object attributes and the object name from 

the object; 

packing the object attributes and the object name as data; 

communicating the data and the request from the first 

adapter to a second adapter; 
searching a meta data map comprising at least one object 

name using the object name to determine whether the 

object name exists in the meta data map; 
if the meta data map contains the object name, using the 

object attributes and the meta data to generate at least 

one command for accessing the data store according to 

the request; 
executing at least one such command; 
obtaining data store content and an execution status based 

on executing at least one such command; 
processing the data store content using meta data; 
packing data store content, if found, as data; 
communicating the data and the execution status from the 

second adapter to the first adapter; 
unpacking the data; 

instantiating the object attributes and the object name into 
at least one new object and/or status according to the 
request and the data; and 

communicating the request and at least one such new 
object from the first adapter to the application program. 

* + * % + 
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